feat(wallets): createServerSigner returns a sign(message) function - #2276

Description

Problem

A backend that holds a server signer secret can derive its address with createServerSigner(), but cannot sign with it. The function returns { type, address, keyBytes } and nothing else. When the API asks that signer for an approval (a transaction or signature approval, or a quorum member's approval message), the developer has to rebuild the signing per chain from keyBytes: viem signMessage with { raw } on EVM, ed25519 over the base58 message on Solana, ed25519 over the base64-decoded message with base64 out on Stellar. Calling signer.sign(message) fails with TypeError: signer.sign is not a function, and a wrong rebuild is only caught when the API rejects the approval.

What this PR does

• createServerSigner() also returns sign(message). It delegates to the same EVMServerSigner, SolanaServerSigner and StellarServerSigner the SDK uses when a server signer approves on its own, so the output is what the API already accepts.
• keyBytes is left intact: the adapter wipes the bytes it is given, so it gets a copy.
• Message and signature encodings follow the chain: EVM 0x-hex in and out, Solana base58, Stellar base64.

flowchart LR
    subgraph Before
    A1["createServerSigner()"] --> B1["address + keyBytes"] --> C1["caller re-implements per-chain signing"]
    end
    subgraph After
    A2["createServerSigner()"] --> B2["address + keyBytes + sign"] --> C2["sign(pending.message)"] --> D2["POST under server:address"]
    end

Result

Unchanged: address, keyBytes, CreateServerSignerParams. ServerSigner gains a required sign field; code that only reads the existing fields is unaffected, code that constructs a ServerSigner literal by hand would need to add it.

What to check when reviewing

• utils/server-signers/createServerSigner.ts: reuse of assembleServerSigner, and the keyBytes.slice() copy.
• Nothing new is signed: this exposes what the wallet's server-signer path already does. Server signers stay Node-only (the Stellar adapter uses the global Buffer).
• Overlap: feat(wallets): approve as a quorum member (EVM + Stellar quorum E1) #2255 (approve as a quorum member) signs a server signer's member messages through the same adapters' signMessage, inside wallet.approve, and adds no standalone sign helper, so this does not duplicate it. If feat(wallets): approve as a quorum member (EVM + Stellar quorum E1) #2255's wallet-level path covers a caller's need, sign is still the way to sign outside a wallet. Same wallet.ts stack as feat(wallets): read quorum signer entries (quorum foundation 1/3) #2214, feat(wallets): approval collection and poll outcome for quorum approvals (quorum foundation 4/4) #2225, feat(wallets): acting-signer seam, held signers and quorum API errors at call sites (quorum foundation 3/4) #2233, feat(wallets): a member-only key acts as its quorum (EVM + Stellar quorum E2) #2256, feat(wallets): signer changes approved by a recovery quorum (EVM quorum E3) #2261, feat(wallets): a quorum acting signer returns the created transaction unsigned, as prepareOnly does (quorum foundation 5/5) #2268, but this PR touches none of those files.

Test plan

• pnpm --filter @crossmint/wallets-sdk test:vitest: 770 tests pass. src/api/client.test.ts needs PREVIEW_CK_KEY and was not run locally; unrelated.
• New tests in createServerSigner.test.ts (8): EVM signature recovers to the address; Solana and Stellar signatures verify against the address's key; EVM, Solana and Stellar reject malformed messages; repeated signing works; keyBytes unchanged. All 8 fail against the old source.
• pnpm biome check and the package build pass.
• Not yet run: signing a real pending approval on staging.

Package updates

• @crossmint/wallets-sdk minor changeset (.changeset/server-signer-sign.md)

Checklist

• Tests fail on the old code
• Changeset added
• No existing field changed
• Staging run recorded

Rollback

Revert the commit; sign is additive and nothing else reads it.

Closes WAL-13399

🤖 Generated with Claude Code